Codecov Report

❌ Looks like you've decreased code coverage for some files. Please write tests to increase, or at least maintain, the existing level of code coverage. See our documentation here for how to interpret this table.

@aimane-chnaif Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

@mountiny can you run another adhoc build here? @aimane-chnaif I think I resolved the remaining bugs, could you check again?

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

Regression review

I reviewed the diff focusing on (a) blast radius outside the money-request report view and (b) behavioral regressions in the migrated list. Three likely regressions, all inside MoneyRequestReportView — the shared-component and deleted-file changes are clean.

🔴 Confirmed regressions

1. Wide-table horizontal scroll position is no longer restored
On wide tables, the horizontal offset is lost on any transaction-data change (sort, new transaction, RBR reorder). main restored it via a useLayoutEffect keyed on the transactions; the new ExternalScrollFlashListTable.tsx:189-212 renders the horizontal ScrollView with no ref, no onScroll capture, and no restoration effect. The controller still computes horizontalScrollRestorationKey and documents it as "used to restore the previous offset" (MoneyRequestReportTransactionList.tsx:1088), but nothing consumes it → the table snaps back to the left column. (High confidence)

2. New/sent-message autoscroll still uses estimated scrollToEnd on large lists
The pill and send path were moved to indexed scrollToBottom, but useScrollToEndOnNewMessageReceived is still wired to reportScrollManager.scrollToEnd (MoneyRequestReportActionsList.tsx:497-507 → hook useScrollToEndOnNewMessageReceived.ts:81). So when another participant's message arrives while the user is at the bottom of a large transaction+chat report, autoscroll can land on the blank estimated end — the exact failure mode the indexed jump was added to avoid (author's own comment, L104-L106). (High confidence — this is the codex P2 flag, validated.)

3. Cold-open deep-link to a report action may not anchor
initialScrollIndex is a mount-only hint; if the linked action isn't in visibleReportActions at first mount, MoneyRequestReportUnifiedList.tsx:197-198 yields -1/undefined and there's no post-mount re-anchoring (the removed FlatListWithScrollKey re-derived the index from the reportActionID key across data growth). maintainVisibleContentPosition (default-on) keeps things stable once anchored, so the gap is specifically the cold deep-link open before the linked action paginates in. (Medium confidence — codex P1, partially validated; worth a quick manual test of a linked-message deeplink into a long report.)

Confirmed with code evidence; #1 and #2 are straightforward to reproduce on a large report. Reply with @MelvinBot <feedback> to dig deeper into any of these.

Blockers

• TableBody.tsx change (flexGrow1 → flex1) is no longer necessary

• useScrollToEndOnNewMessageReceived still uses scrollToEnd

The PR added scrollToBottom and moved every current-user-message path onto it, explicitly because the PR itself comments that scrollToEnd leaves the bottom blank on large lists.
But useScrollToEndOnNewMessageReceived is still fed the raw reportScrollManager.scrollToEnd.
That hook fires when a message arrives from any account while the user is near the bottom — the same "hundreds of transactions + chat" scenario the PR sized the fix for.
Route it through scrollToBottom too.

Repro: Receive the message coming from another account/device (not current user).

New concerns introduced by the ExternalScrollFlashListTable architecture

C1. LayoutManager is not initialized swallow is string-matched

ExternalScrollFlashListTable.tsx:108-111:

} catch (error) {
    if (!(error instanceof Error) || !error.message.includes('LayoutManager is not initialized')) {
        throw error;
    }
}

The back-navigation crash fix (commit b5dc428eb74) works by ignoring specifically-worded errors from FlashList. If the upstream ever rewords that message — e.g. LayoutManager not initialized, or moves it behind a typed error — the catch stops matching and the crash resurfaces. Either sync the message into a shared constant with FlashList (given you already patch it) or catch a specific error class.

C2. Nested FlashList viewportHeight starts at 0 on first paint

MoneyRequestReportUnifiedList.tsx:143: const [viewportHeight, setViewportHeight] = useState(0);. Before the outer FlashList's onLayout fires, viewportHeight is 0, which flows into ExternalScrollFlashListTable's overrideWindowSize={{width: contentWidth, height: 0}}. FlashList windows against a zero-height viewport — nothing to render, drawDistance clamps to zero effective coverage.

Usually harmless because onLayout fires on the next frame, but on cold navigation into a wide-table report you can catch a frame where the transactions area is blank / renders only the estimated top row. Consider seeding with windowHeight from useWindowDimensions on first paint.

Repro: cold-navigate to a wide-table report and screenshot the first frame after the navigation transition.

C3. scrollOffsetStore not reset when isHorizontalTable transitions on the same report

MoneyRequestReportUnifiedList.tsx:150-154 resets the offset store on report.reportID change, but not when isHorizontalTable toggles. If the user is in inline mode, scrolls the list, then drags the browser narrow enough for isHorizontalTable to flip:

• The store still holds 0 because handleScroll only writes when isHorizontalTable === true.
• The outer FlashList's actual contentOffset.y is at whatever the user scrolled to.
• The nested ExternalScrollDriver.emit() runs with the stale 0, so the nested table paints the top rows even though the outer list is scrolled hundreds of pixels down.

Correction happens on the next scroll event, but the first frame after the transition shows top-of-table content. Reset the store on any isHorizontalTable change (or better, always feed it in handleScroll and just ignore consumers when inline).

C4. Deep-link (initialScrollIndex) into a transaction row is silently unsupported

MoneyRequestReportUnifiedList.tsx:197-198 computes linkedActionLocalIndex only against visibleReportActions. If a deep link ever targets a transaction row (indirect flow — e.g. some Onyx-side redirect turns a reportActionID into a transactionID in the URL), the finder returns -1, initialScrollIndex = undefined, and the wide-table case never scrolls anywhere near it. Not a regression (the original code was the same) but the wide-table hop through overrideWindowSize makes this actively harder to fix later — worth noting.

C5. Nested FlashList shares the getItemType bug

Still H3-style: unifiedListItemType returns 'section-header' / 'transaction' / 'transactions-footer' / 'report-action' for the outer list, and the same function is re-used as the nested table's getItemType. Different transaction rows (grouped vs regular, with-receipt vs without) all share the 'transaction' bucket, so recycling can shuffle rows with very different DOM subtrees. Same chat-list migration lesson — either bucket by transaction.hasReceipt / columns.length or narrow the type down.

C6. Neither the outer nor the nested FlashList sets extraData

Same as H2 in prior rounds. Selection toggles, column visibility changes, and highlight-set changes don't touch data identity for the transactions section. React Compiler may catch some of it, but the safety net (extraData=[selectedTransactionIDs, columnsToShow, highlightedTransactionIDs, currentGroupBy]) is one line and eliminates the class of bugs. Applies to both the outer and the nested <FlashList>.

C7. handleScroll / handleLayout / dispatchRenderItem / nested renderItem are all inline closures

New function identity every render:

• MoneyRequestReportUnifiedList.tsx:156, 164, 183
• ExternalScrollFlashListTable.tsx:199 — renderItem={({item, index}) => renderItem(item, index, {isFirst, isLast})}
• Inline style={{...}} object on ExternalScrollFlashListTable.tsx:209

FlashList's internal optimizations (memoized cell wrappers) rely on stable identity to skip work. All of these fire every parent render regardless of what changed. memo(MoneyRequestReportUnifiedList) on line 266 also bails on every render because controller is a fresh object literal — same R13 code smell as before.

C8. MoneyRequestReportFlashList shim is now dead code

MoneyRequestReportUnifiedList.tsx:46-64 exists specifically to launder FlatListRefType into a FlashListProps.ref. But FlatListRefType now lives at @components/FlashList/types (per line 2) and is presumably already the correct type. The wrapper is a bare {...props} spread — no runtime purpose. Either delete or explain the safety it still buys.

Bug when resize window

this branch:

production:

10. Send a message on the report and verify you are scrolled to the bottom of the list

Sometimes this doesn't work. Not consistent.
I have ever reproduced in staging but not found reliable repro step.
So I'd say this is not blocker.

1. Wide-table horizontal scroll position is no longer restored

not valid - ScrollView does not re-position unless it's re-mounted

2. New/sent-message autoscroll still uses estimated scrollToEnd on large lists

fixed in 71f12e8

3. Cold-open deep-link to a report action may not anchor

fixed in 1814a1ee60a8a7ecee5693e468b43eee14713484

C1. LayoutManager is not initialized swallow is string-matched

fixed in 970d609

C2. Nested FlashList viewportHeight starts at 0 on first paint

fixed in 335748a

C3. scrollOffsetStore not reset when isHorizontalTable transitions on the same report

fixed in 335748a

C4. Deep-link (initialScrollIndex) into a transaction row is silently unsupported

Nothing in the codebase ever writes a transactionID into that param. I don't think we should write code for a flow that does not exist

C5. Nested FlashList shares the getItemType bug

not valid

C6. Neither the outer nor the nested FlashList sets extraData

I don't think we have any bug introduced by lack of extraData so I am not in favor of adding this unless necessary

C7. handleScroll / handleLayout / dispatchRenderItem / nested renderItem are all inline closures

React Compiler handles this

C8. MoneyRequestReportFlashList shim is now dead code

not valid

I'll check the resize and send message bugs soon

@aimane-chnaif I can't reproduce the resize bug - can you verify again? Might be accidentally fixed by one of my recent commits 😅

🚧 mountiny has triggered a test Expensify/App build. You can view the workflow run here.

also couldn't reproduce the issue with the scroll after msg

🧪🧪 Use the links below to test this adhoc build on Android, iOS, and Web. Happy testing! 🧪🧪
Built from App PR #91422.

Android 🤖	iOS 🍎
https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-android-Adhoc-d87908c940d-aa76580-7d125ed567957b2b4a49e6515b12168e347a47e5/index.html	https://ad-hoc-expensify-cash.s3.us-east-1.amazonaws.com/rock-artifacts/ad-hoc/rock-ios-device-AdHoc-d87908c-aa76580-bca878b66e259b7d14480a9ddcb4f686621139ce/index.html

Web 🕸️
https://91422.pr-testing.expensify.com

👀 View the workflow run that generated this build 👀

After resize window, blank screen briefly appears. (00:04s)

Also when scroll fast (00:42s)